To be honest I'd be more inclined to remove the unused stmtcache.UnlimitedCache rather than expose it. If I recall correctly, it was originally implemented as part of the internal functionality for preparing all statements used by a batch at once. But the final version didn't need it. I would consider it committed in error.

I also don't think encouraging an unlimited cache size is a good idea. I think an unlimited or extremely large cache size is more likely to cause problems such as OOM on the PostgreSQL server. While I was unable to find any definite benchmarks or rules, my understanding is that more than 1,000 prepared statements is asking for trouble. For reference, pgx's default max cache size is 512.

If you really want an unlimited cache size you can do that now by setting the cache size to math.MaxInt.

Hi, thanks for the quick response!

My use case was quite simple: I have an app with a limited number of queries (all generated by sqlc, no dynamic ones) and therefore I don't need to limit the cache size and I wanted to opt-in for a simpler cache implementation. My goal wasn't to really allow thousands of queries, but to simply don't bother with limiting them since it is a wasted time in my case. I think the lib users should have power to control stuff like that.

But your points are of course valid and if you chose to remove it instead, I'll live.

What if we add warning to the AllowUnlimitedCacheCapacity that mentions these possible issues to the user?

Let me know -> I'll either add the comment, or change the PR to remove it.

What if we add warning to the AllowUnlimitedCacheCapacity that mentions these possible issues to the user?

I'm still against it. As mentioned above it would almost always be a mistake to set cache size above 1000. And if you really do need unlimited, you can set it to math.MaxInt.

Let me know -> I'll either add the comment, or change the PR to remove it.

Let's change it to remove UnlimitedCache.

✔️